Introduction

Most of the time, confidentiality is not enough - it needs to be combined with integrity in order for an application to be secure. So, even if an encryption scheme is CCA-secure, there is still room for ciphertext forgery. This necessitates even stronger security notions which are satisfied by authenticated encryption schemes.

Definition: Authenticated Encryption (AE-Security)

A cipher is an authenticated encryption scheme or is AE-secure if it is CPA-secure and provides ciphertext integrity (CI).

AE-security is the most widely adopted security notion and is ubiquitous in web applications. It is stronger than CCA-security - the constructs which satisfy AE-security also satisfy CCA-security. However, there is no real efficiency difference between ciphers which are AE-secure and ciphers which are only CCA-secure.

Theorem: AE-Security implies CCA-Security

Every AE-secure cipher is also CCA-secure.

Proof: AE-Security implies CCA-Security

Let be an AE-secure cipher and let be a CCA-adversary. In particular, suppose that Mallory makes encryption queries to obtain the plaintext-ciphertext pairs and also makes decryption queries to obtain the ciphertext-plaintext pairs .

Since the cipher is AE-secure and thus provides ciphertext integrity, the probability that in a given decryption query Mallory finds a ciphertext such that is negligible. Mallory sumbits queries, so the probability that any of them turn out to be valid is , which is also negligible. This means that the decryption queries do not help Mallory in any way and can be ignored, thereby reducing the CCA scenario to a CPA one. AE-security provides CPA-security by definition, which completes the proof.

This explains why ciphers which are only CCA-secure are rarely used in practice - why would you opt for less security when there is not even an efficiency benefit?

Implementation

There are many ways to implement authenticated encryption. Some include combining a CPA-secure cipher with a secure

Construction from a Cipher and a MAC

AE-secure encryption schemes can be constructed by combining a CPA-secure cipher with a CMA-secure message authentication code system . Such approaches use two separate keys - for encryption / decryption and for message signing and verification. These keys must be independent of each other.

However, it turns out that not all ways of combining these two systems yield an authenticated encryption and even if the correct approach is used, the keys and must still be completely independent, lest AE-security is broken.

Encrypt-and-Sign

In this approach, encryption and message signing are carried out independently from each other and in parallel. The supposedly AE-secure cipher is constructed by encrypting the message with some encryption function to produce a ciphertext . The message is also separately signed by the MAC and the resulting tag is appended to .

The final ciphertext is the concatenation of and the message tag , i.e.

To decrypt the ciphertext , the decryption function first parses it back into a message ciphertext and a message tag . It then decrypts the ciphertext using to obtain the message . Finally, it verifies the decrypted message with the tag . If the message is valid, then it is returned. Otherwise, an error is produced.

This is certainly a good attempt at constructing an authenticated encryption but it fails horribly.

Warning

The Encrypt-and-Sign approach is not AE-secure.

Since the message is signed directly before being encrypted, nothing is stopping the tag from leaking information about it (CMA-secure MACs provide no secrecy guarantees). For example, a MAC might be CMA-secure but have tags whose first bit is always identical to the first bit of the message. This means that the Encrypt-and-Sign method might not even be semantically security.

Moreover, it is not CPA-secure because deterministic MACs will produce the same tag when given the same message, provided that the same signing key is used. This is a real concern, since most MAC systems used in practice are deterministic.

Sign-then-Encrypt

In this approach the first step is to compute the tag of the message , i.e. . It is then appended to the message and the resulting concatenation is what actually gets encrypted to obtain the ciphertext .

The decryption function decrypts the ciphertext to obtain the concatenation of the message with the tag and then verifies them. If either or validation result in an error, then simply errors out.

Warning

The Sign-then-Encrypt approach may be AE-secure, but this depends highly on the specifics of the cipher and the MAC used. Since it does not provide AE-security in the general case of an arbitrary cipher and an arbitrary MAC, it should be avoided - there is simply too much room for mistakes when implementing it.

For example, if there are different error types depending on whether validation or decryption fails, something which is very much necessary in practice, then the security of this approach can be broken by padding oracle attacks.

Encrypt-then-Sign

This approach requires a MAC system with strong unforgeablity. First, the message is encrypted. The resulting ciphertext is then signed and the tag is appended to it to obtain the final ciphertext.

The decryption function parses the ciphertext back into a message ciphertext and a ciphertext tag . If ciphertext verification fails, then it returns an error. Otherwise, it returns the decryption of .

This approach is quite similar to Encrypt-and-Sign, but the tag is computed on the ciphertext instead of the plaintext. This small difference turns out to be crucial as it is what makes Encrypt-then-Sign AE-secure. Since the tag is verifying the ciphertext, no adversary can tamper with it. This reduces any CCA adversary to a CPA adversary and the CPA-security of guarantees protection against this.

Proof: AE-Security of Encrypt-then-Sign

Suppose that is a CCA adversary.

For each of the adversary's decryption queries, the strong unforgeability of the MAC guarantees that the probability that can produce a valid ciphertext is negligible, since to produce such a ciphertext, would have to find a valid ciphertext-tag pair. The MAC system is secure, so this only happens with probability at most , which is negligible. If makes decryption queries, then the probability that one of them is valid is which is also negligible, since has to be polynomial. This means that the cipher provides ciphertext integrity (CI), even in the more empowering scenario which allows to submit decryption queries.

What remains is to prove that the cipher is CPA-secure (remember that CPA-security combined with the already established ciphertext integrity implies CCA-security). Suppose, towards contradiction, that is a CPA adversary which can break the CPA-security of , i.e. can distinguish if a ciphertext is the encryption of or with probability .

Now, let be a CPA adversary against . When receives its challenge ciphertext , it will compute its tag (this is allowed because the signing key is different from the encryption key ) and then it will forward together with and to . However, the adversary is also a CPA adversary (albeit against ) and may thus require encryption queries to achieve its goal. This is no problem as can provide answers to any encryption queries that might have. Whenever submits a plaintext as a query, the adversary will be able to fulfil it by using its own encryption oracle and then computing the tag for the resulting ciphertext.

Ultimately, will output whichever message, either or , that does. Since will guess correctly if is the encryption of or with probability , then will guess if is the encryption of or with probability . This is a contradiction, since it would be a breach of the CPA-security of .

It is paramount that the MAC system used has strong unforgeability. Otherwise, a CCA adversary challenged with a ciphertext can generate a new valid tag for with non-negligible probability. Since , the adversary is allowed to submit this new tag with to its decryption oracle which will pass verification. The decryption oracle will then hand the exact decryption of to the adversary and so they will know for sure if was the encryption of some message or another message . This would be a breach of CCA-security and therefore also a breach of AE-security.